D:\git\skunkworks\herald-for-cpp\herald\include\herald\ble\ble_sensor_configuration.h
Line | Count | Source |
1 | | // Copyright 2020-2021 Herald Project Contributors |
2 | | // SPDX-License-Identifier: Apache-2.0 |
3 | | // |
4 | | |
5 | | #ifndef HERALD_BLE_SENSOR_CONFIGURATION_H |
6 | | #define HERALD_BLE_SENSOR_CONFIGURATION_H |
7 | | |
8 | | #include "../datatype/time_interval.h" |
9 | | #include "../datatype/uuid.h" |
10 | | |
11 | | namespace herald { |
12 | | namespace ble { |
13 | | |
14 | | using namespace herald::datatype; |
15 | | |
16 | | /// \brief Legacy Australia COVIDsafe service UUID |
17 | | static const UUID legacyAustraliaServiceUUID("00000000-0000-4000-8000-000000000000"); // TODO fill this value in |
18 | | /// \brief Legacy OpenTrace service UUID |
19 | | static const UUID legacyOpenTraceUUID("00000000-0000-4000-8000-000000000000"); // TODO fill this value in |
20 | | |
21 | | |
22 | | /// Defines BLE sensor configuration data, e.g. service and characteristic UUIDs |
23 | | struct BLESensorConfiguration { |
24 | | BLESensorConfiguration(); |
25 | | BLESensorConfiguration(const BLESensorConfiguration& other); |
26 | 32 | ~BLESensorConfiguration() = default; |
27 | | |
28 | | // MARK:- BLE service and characteristic UUID, and manufacturer ID |
29 | | |
30 | | /// Service UUID for beacon service. This is a fixed UUID to enable iOS devices to find each other even |
31 | | /// in background mode. Android devices will need to find Apple devices first using the manufacturer code |
32 | | /// then discover services to identify actual beacons. |
33 | | /// - Service and characteristic UUIDs are V4 UUIDs that have been randomly generated and tested |
34 | | /// for uniqueness by conducting web searches to ensure it returns no results. |
35 | | UUID serviceUUID; |
36 | | /// Signaling characteristic for controlling connection between peripheral and central, e.g. keep each other from suspend state |
37 | | /// - Characteristic UUID is randomly generated V4 UUIDs that has been tested for uniqueness by conducting web searches to ensure it returns no results. |
38 | | UUID androidSignalCharacteristicUUID; |
39 | | /// Signaling characteristic for controlling connection between peripheral and central, e.g. keep each other from suspend state |
40 | | /// - Characteristic UUID is randomly generated V4 UUIDs that has been tested for uniqueness by conducting web searches to ensure it returns no results. |
41 | | UUID iosSignalCharacteristicUUID; |
42 | | /// Primary payload characteristic (read) for distributing payload data from peripheral to central, e.g. identity data |
43 | | /// - Characteristic UUID is randomly generated V4 UUIDs that has been tested for uniqueness by conducting web searches to ensure it returns no results. |
44 | | UUID payloadCharacteristicUUID; |
45 | | |
46 | | /// Manufacturer data is being used on Android to store pseudo device address |
47 | | /// - Pending update to dedicated ID |
48 | | int manufacturerIdForSensor; |
49 | | /// BLE advert manufacturer ID for Apple, for scanning of background iOS devices |
50 | | int manufacturerIdForApple; |
51 | | |
52 | | // MARK:- BLE signal characteristic action codes |
53 | | |
54 | | /// Signal characteristic action code for write payload, expect 1 byte action code followed by 2 byte little-endian Int16 integer value for payload data length, then payload data |
55 | | std::byte signalCharacteristicActionWritePayload; |
56 | | /// Signal characteristic action code for write RSSI, expect 1 byte action code followed by 4 byte little-endian Int32 integer value for RSSI value |
57 | | std::byte signalCharacteristicActionWriteRSSI; |
58 | | /// Signal characteristic action code for write payload, expect 1 byte action code followed by 2 byte little-endian Int16 integer value for payload sharing data length, then payload sharing data |
59 | | std::byte signalCharacteristicActionWritePayloadSharing; |
60 | | /// Arbitrary immediate write |
61 | | std::byte signalCharacteristicActionWriteImmediate; |
62 | | |
63 | | // MARK:- App configurable BLE features |
64 | | |
65 | | /// Log level for BLESensor |
66 | | //SensorLoggerLevel logLevel = SensorLoggerLevel.debug; |
67 | | |
68 | | /// Payload update at regular intervals, in addition to default HERALD communication process. |
69 | | /// - Use this to enable regular payload reads according to app payload lifespan. |
70 | | /// - Set to .never to disable this function. |
71 | | /// - Payload updates are reported to SensorDelegate as didRead. |
72 | | /// - Setting take immediate effect, no need to restart BLESensor, can also be applied while BLESensor is active. |
73 | | TimeInterval payloadDataUpdateTimeInterval; |
74 | | |
75 | | /// Expiry time for shared payloads, to ensure only recently seen payloads are shared |
76 | | TimeInterval payloadSharingExpiryTimeInterval; |
77 | | |
78 | | /// Advert refresh time interval |
79 | | TimeInterval advertRefreshTimeInterval; |
80 | | |
81 | | /// Remove peripheral records that haven't been updated for some time. |
82 | | /// - Herald aims to maintain a regular "connection" to all peripherals to gather precise proximity and duration data for all peripheral records. |
83 | | /// - A regular connection in this context means frequent data sampling that may or may not require an actual connection. |
84 | | /// - For example, RSSI measurements are taken from adverts, thus do not require an active connection; even the connection on iOS is just an illusion for ease of understanding. |
85 | | /// - A peripheral record stops updating if the device has gone out of range, therefore the record can be deleted to reduce workload. |
86 | | /// - Upper bound : Set this value to iOS Bluetooth address rotation period (roughly 15 minutes) to maximise continuity when devices go out of range, then return back in range (connection resume period = 15 mins max). |
87 | | /// - Lower bound : Set this value to Android scan-process period (roughly 2 minutes) to minimise workload, but iOS connection resume will be more reliant on re-discovery (connection resume period = 2 mins or more dependent on external factors). |
88 | | /// - iOS-iOS connections may resume beyond the set interval value if the addresses have not changed, due to other mechanisms in Herald. |
89 | | TimeInterval peripheralCleanInterval; |
90 | | |
91 | | /// Connection management |
92 | | /// Max connections - since v1.2 (allowing multiple connections on Android and C++) |
93 | | int maxBluetoothConnections; // Same as NRF 52840 max connections |
94 | | |
95 | | // Does this Herald application support advertising? |
96 | | bool advertisingEnabled; |
97 | | // Does this Herald application support scanning? (Simple Venue Beacons don't) |
98 | | bool scanningEnabled; |
99 | | |
100 | | |
101 | | }; // end struct |
102 | | |
103 | | } // end namespace |
104 | | } // end namespace |
105 | | |
106 | | #endif |